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UNIFIED DATA TYPE SYSTEM AND ^ fields in an object. Thus, in Java, for example, a pro- 

METHOD grammer can define a variable of type integer and define an 

object with fields, one of which is of the "integer" data type. 

CROSS REFERENCE TO RELATED [a object oriented programming languages, there can be 

APPLICATIONS s different treatment for objects and basic data types. For 

_ A . . *■ • , f ,Tc example, an object with a single property of type integer and 

The present application is a continuation-in-part of U.S. ? * c / . °\, r f 3 J ,* ... c 

patent application Ser. No. 09/613,289, entitled UNIFffiD » vlrlable ° f ^ mte .g cr would ° ot b < «=°^ered to be of 

DATA TYPE SYSTEM AND METHOD, filed on Jul. 10, ^ ,t \T "IT? °, J °T ■ T^' 

onnn u a a although at the bottom, both simply represent an integer. The 

now at,anaonc0 - 10 variable of type integer simply exists as a bit pattern in a 

TECHNICAL FIELD particular storage location with no additional information, 

while the object has a storage location of the same size and 

The present invention relates to a system and method for additional information (or "metadata' 1 ) that describes how to 

defining and processing data types and more particularly interpret the value in the storage location, 

relates to type systems used by a compiler and/or runtime is To provide some sort of equivalency between an object 

environment. representation and a basic data type representation, the 

r» a ^^DrtTTvrr* nc titc iM\/rwnnM notion of <<boxin g" was conceived. The process of adding 

BACKGROUND OF THE INVENTION mt{ ^ to a basic daU type representalion to yield an 

Almost from the beginning, computer programming lan- object representation is termed "boxing". Similarly, remov- 

guages have embodied the notion of data types. Data types 20 ing the metadata from an object representation to yield a 

include such basic concepts as a character, string, integer, basic data type representation is termed "unboxing", 

float, and so forth. At its lowest level, data stored in a However, even with the development of boxing and 

computer is a simple bit pattern stored in a location of a unboxing, present compilers and/or runtime systems use a 

particular size (e.g., a 32-bit memory location). Data types fragmented notion of data types with strict separation 

define the notion of how to interpret the bit pattern. For 25 between the notion of objects and the notion of basic data 

example, a particular bit pattern in a storage location of a type representations. Although this separation has many 

particular size might be interpreted one way if the storage implications, one area where the implications are quite 

location was deemed to hold a "character" and another way apparent is in how these languages treat user-defined types, 

if the storage location was deemed to hold an "integer". ^ Even prior to object oriented programming, many, if not 

In some computer languages, although the notion of data most, programming languages had the notion of user- 
type exists, few rules are enforced either by the compiler or defined data types. These programming languages allowed a 
any associated runtime for mixing of different data types in programmer to build up new "data types" from the basic 
expressions of a computer program. So no compiler error built-in types of the language. For example, a programmer 
will be generated in the C programming language, for 35 could define a new type "data_point" as consisting of an x 
example, if an integer value is multiplied by a floating point coordinate value of type float and a y coordinate value of 
number value. In order to minimize various types of errors, type float. Certain object oriented programming languages, 
many such languages had built-in type rules that allowed for like Java, however, do not allow extension of the basic 
the implicit conversion of certain data types. In other built-in types in this manner. In some such implementations, 
instances, languages included explicit constructs to "coerce" 40 user-defined types are only allowed in the form of objects, 
or convert one data type into another data type. Needless to Existing solutions have also failed to adequately address the 
say, although such languages provided great flexibility, need for a unified data type system that can be applied 
certain programming errors could be introduced if care was during runtime. 

not taken when mixing data types in various programming The present invention addresses, among other things, a 

expressions. 45 mechanism to avoid the currently fragmented view of data 

Strongly typed languages tried to reduce the instances of types. The invention also addresses the inefficiencies asso- 

programming errors by enforcing strict typing rules. In ciated with using basic data types where object types would 

strongly typed languages, a compiler error would be gener- be more efficient and object types where basic data types 

ated when data type mismatches were detected. For would be more efficient, 

example, a compiler error would be generated in Pascal if a 50 IW , /CWTinw 

programmer tried to assign a character value to an integer SUMMARY OF THE INVENTION 

variable. This had the effect of reducing certain types of fa accordance with the present invention, the above and 

programming errors, but the rules seemed to be too restric- other problems are solved by providing a system and method 

live. for efficiently processing user-defined data types. The 

With the advent of object oriented programming 55 present invention provides for a more unified view of the 

languages, the concept of data types took on new meaning. type system of programming languages, and object oriented 

In object oriented languages, objects may typically be rep- programming languages in particular. In the present 

resented by an object class hierarchy, where some objects invention, the type system includes a dual representation for 

are derived from (or inherit) fields (also referred to as basic data types. One representation is the basic data type 

properties) and methods from other "base class" objects. 60 representation common to such basic built-in data types. In 

Objects in these languages can be a mixture of fields this application this representation will be referred to as a 

(typically represented by variables of a particular data types) value type representation, or more simply, a value type, 

and methods or functions which allow manipulation of the However, unlike other type systems, each of the basic data 

fields or which provide certain functionality. In addition, types also has a boxed representation that exists in the object 

object oriented languages also typically include a number of 65 hierarchy of the type system itself. This dual representation 

built-in data types, such as float, integer, character, string can also be extended to user-defined types, so that user- 

and so forth, which can be used either as basic variables or defined types may exist both as a value type and as an object 
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within the object hierarchy of the type system. This allows least one unboxed value type representation. The computer 

the compiler and/or runtime to select the most effective and program product encodes a computer program for executing 

efficient representation for the data type depending on the on a computer system a computer process for compiling a 

particular need at the moment. source file containing at least one unboxed value type 

In addition to the dual representation of data types, 5 representation. It is determined that the source file includes 

another aspect of the invention allows for the application of the unboxed value type representation. Metadata is associ- 

rules to determine when to use the boxed representation and *ted with the unboxed value type representation, responsive 

when to use the value type (or unboxed) representation of a to the determining operation. An operation having operands 

data type. These rules can be applied, for example, by a wilh differing types is specified in the source file. One 

compiler and allow, among other things, for implicit con- 1° operand is the unboxed value type representation and 

version between the boxed and unboxed representations of another operand is a boxed value type representation. Output 

a particular data type coc * e ^ emitted from the compiler for converting one of the 

In another aspect of the invention, the unified view of the °P erands match the ^ e of me other °P erand ' 

type system is reflected in the behavior of virtual methods In a further aspect of the invention, the notion can be 

for objects. One basic feature of objects is that they can 15 combined with a runtime or execution environment to 

inherit methods from "parent" objects. Such methods may produce a unique runtime environment that supports value 

include methods that take objects as arguments. The dual types, object classes, and interfaces, 

representation of value types both as value types and as These and various other features as well as advantages, 

objects in the hierarchy implies that value types can have which characterize the present invention, will be apparent 

methods and can behave as objects in some instances and as 20 from a reading of the following detailed description and a 

value types in other instances. Although the details are review of the associated drawings, 
discussed more completely below, the practical effect is that 

when value types are in their boxed representation, they can BRIEF DESCRIPTION OF THE DRAWINGS 

possess type information like other objects. Furthermore, nG x d ^ a } ^ rc tation of an cxcmplary 

when value types are in their unboxed I representation, they ^ ^ ^ ide & unified yiew of a 

can be valul arguments to methods that would otherwise ^ ^ tQ m * mlx)dillirat of mc prcscGt invcn . 

expect an object type (such as a boxed representation). This ^ 

approach provides entirely new and powerful programming . - , . 

paradigms to developers. Furthermore, since both boxed and FIG ; 2 ^trates a computer system that provides the 

unboxed representations are available, all this functionality 30 operating environment for an exemplary embodiment of the 

can be provided without the developer having to explicitly present invention. 

specify in the source code the value type version (i.e., boxed FIG. 3a depicts an exemplary value type list used in an 

or unboxed) to use or the conversion from one form to exemplary embodiment of the present invention to catego- 

another. rize data types. 

In one implementation of the present invention, a unified FIG. 36 depicts an exemplary object class hierarchy used 

type system is provided in a runtime environment A source in an exemplary embodiment of the present invention to 

code file includes an unboxed value type representation. organize objects. 

Metadata is associated with the unboxed value type repre- FIG. 4 depicts a set of boxed and unboxed data types, 

sentation for converting the unboxed value type represen- 4Q pi G 5 depicts a more detailed logical representation of 

tation into a boxed value type representation. Output code is the exem pi ary compiler system of FIG. 1. 

generated from the compiler converting between the n(} fi iUustrates a method for boxi and unboxi a 

unboxed value type representation and the boxed value type ^ m an { embodiment of the present 

representation in response to a detection of different types in invention 

a runtime operation. . , r • , . . - 

. . , - ^ , FIG. 7 illustrates a method for implementing the boxing 

In another implementation of the present invention, a and unboxi of a value t al nintime in an embodiment 

method for compiling a source file containing at least one of ^ t invemion 
unboxed value type representation is provided. It is deter- 

mined that the source file includes the unboxed value type FIG * 8 Annates an alternative method for implementing 

representation. Metadata is associated with the unboxed , 0 *c boxing ^d unboxing of a value type at runtime in an 

value type representation, responsive to the determining embodiment ot the present invention, 

operation. An operation having operands with differing DETAILED DESCRIPTION OF THE 

types is specified in the source file. One operand is the INVFNTION 
unboxed value type representation and another operand is a 

boxed value type representation. Output code is emitted 55 Exemplary embodiments of the present invention provide 

from the compiler for converting one of the operands match f or a more unified view of the type system of programming 

the type of the other operand. languages, and object oriented programming languages in 

In other implementations of the present invention, articles particular. An exemplary type system includes a dual rep- 

of manufacture are provided as computer program products. resentation for basic data types. One representation is the 

One embodiment of a computer program product provides a 60 basic data type representation referred to as an unboxed 

computer program storage medium readable by a computer value type or simply as a value type. An unboxed value type 

system and encoding a computer program for compiling a is generally not accompanied by type information in the 

source file containing at least one unboxed value type output code emitted from a compiler. In an embodiment of 

representation. Another embodiment of a computer program the present invention, however, each of the basic data types 

product may be provided in computer data signal embodied 65 also has a boxed representation that exists in the object 
in a carrier wave by a computing system and encoding the hierarchy of the type system and is accompanied by type 
computer program for compiling a source file containing at information (e.g., specified by metadata) in the output code 
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emitted from the compiler. This dual representation can also class Rect 

be extended to user-defined types, so that user-defined types { 

may exist both as an unboxed value type and as an object Cartesian UpperLeft; 

(i.e., boxed value type) within the object hierarchy of the Cartesian UpperRight; 

type system. This allows the compiler and/or runtime to s Cartesian LowerLeft; 

select the most effective and efficient representation for the Cartesian LowerRight; 

data type depending on the particular need at the moment. float area; 

FIG. 1 depicts a logical representation of a compiler 

operating to provide a unified view of a type system in an io 5f ct _ ct 4 _ „ . L „ , - 4 ttn 

n e >u a ™™t ■ JO „ t - * j ' fiu 1ftn The statement "Rect RectObject defines an object "Rec- 

embodiment of the present invention. A source me 11MJ v J f J 

r • ,i . j • ,. tObject (the object name) of class "Rect (the class 

represents .source program code that is prepared in compli- ^ ^ ^ ^ Rect0bject ^ mclude other 

ance with a given programming language specification^ ^ and ^ ^ ^ q « Up p CrLcft » 

including without hmitauon specifications relating to C "LowerLeft", and "LowerRight", of class 

Language, C++, or any other high level source programming « Cartesian (thc class definition of which is not shown) and a 

language or intermediate language. The source file 100 may vahie type « area » of dala type "float". It should ^ be 

include instructions and data for performing one or more understood that the discussion above merely represents an 

operations in a runtime environment 102. In the illustrated exemplary definition of data in a source file, and that 

embodiment, the source file 100 is received by a compiler alternative data structures and syntaxes of data definition are 

104, which translates the source code into output code 108 20 contemplated within the scope of the present invention. 

(e.g., object code or executable code). In an alternative The compiler 104 may include or have access to one or 

embodiment of the present invention, it should be under- more of a variety of built-in data types, including built-in 

stood that the compiler 104 may be incorporated into the value types 114 and a basic object class hierarchy 116, and 

runtime environment 102 (e.g., as a Just-In-Ume (JIT) ^ type rules 118 for converting between and defining the 

compiler) as shown in FIG. 5. relationship between various data types. Generally, built-in 

K i j • 4 * • *■ ,u value types represent value types that are believed to be 

In an alterative embodiment of the present invention, the , , , 

, Cl , ci inn c *u * i * j * * fundamental to the programming language and commonly 

source code of the source file 100 may first be translated into JL u « u _» c 

4 , • & / . . j . t . used by programmers, such as int for an integer, char for 

an intermediate language before being received by the u * j «« .»» r a ** ■ * L 

*le 104 as re resented b an intermediate language 30 a cnaracter » anc * fl° at f° r a floating point number, 

compi , P J Likewise, the basic object class hierarchy 116 includes 

code file 106. It should be understood that the following . , , , , i ■ • . 

. , ,. A . , . , £ , fundamental and commonly used classes in an inheritance 

discussion addresses an embodiment m which source tile . . . i . i * *u u* l. 

. . , ., 1iL ... fc i.j hierarchy. For example, a root class in the hierarchy may 

100 is input to the compiler 104, although it is contemplated , - ' . «„....,. , a * i l 

* • x i_ j * * j • . i i_ • * * define a BasicObject , which mcludes fundamental char- 
that either source code or intermediate code may be input to , .* ' - . . r , . ...... 

iL . . ,. . CiU . . actenstics (e.g., data and functions) of a basic object in the 

the compiler 104 in an embodiment of the present invention. 35 . x & .' c lL . i i_ 

T ■ . j * . , r 4 j . programming language. Children of the root class may be 

Likewise, both source code and intermediate code may have j « . . « ■ l. v, « . ,„ ( . „ . rtU . . , r 

...... , . * j c - j I j defined to inherit or extend the BasicObject class for 

compatible structures and syntaxes for denning data and r . «n. » , , 

*\ . , . . . f ° . . more specific uses. For example, a Shape class and a 

associated data types within the scope oi the present inven- ktn . ,„ r , • u •* r r> ^if- * i j 

^ }r Pomt class may mhent from the BasicObject class, and a 

40 "Rect" class and a "Circle" class may inherit from the 

Generally, a compiler is a program that translates source "Shape" class. The combination of basic classes comprises 

code (or intermediate language code) into object code or an object class hierarchy. Another example object class 

executable code. The compiler derives its name from the hierarchy is illustrated in FIG. 3b and is discussed below, 

way it works, looking at an entire piece of source code and In many programming languages, both built-in value 

collecting and reorganizing the instructions and data therein. ^ types and basic classes may be extended or customized. For 

In some implementations, a second stage includes a linker example, in C language, a developer may define a new value 

that links the compiled object code with other object code to type using the keyword "typedef \ For example, a value type 

produce an executable program. In other implementations, "coordinate" may be defined as a structure containing two 

this linking process is performed just prior to or during floating point numbers representing X-Y coordinates on a 

runtime and is referred to as "late binding" or "runtime ^ Cartesian plane, as set forth below, 

binding". * typedef struct 

As discussed, programming languages typically have a { 

notion of data types. Data within the source file 100 gener- float x; 

ally consists of two data types: (1) value types 110 and (2) float y; 

objects 112. For clarity, classes and object names and 55 } coordinate; 

discussed herein are represented by capitalized names and Likewise, source code may extend the basic object class 
value types and value type variable names are labeled with hierarchy by inheriting or extending one or more of the basic 
lower case names. Data may be defined in a source file as a classes. For example, a user-defined object may extend the 
"value type" using a variable name and an associated type basic Shape class to define a "CustomShape" class. Refer- 
indicator. For example, data representing an index may be 60 ring again to FIG. 1, both built-in value types and user- 
defined as "int index;", where "int" is the data type indicator defined value types may be represented in source code by 
and "index" is the variable name. Alternatively, data may be value types 110, and both basic and user-defined objects may 
defined in a source file as an "object" using an object name, be represented in source code by objects 112. 
a class indicator, and a class definition. For example, the In an embodiment of the present invention, the compiler 
exemplary source code set forth below defines a class called 65 104 may include type rules 118 that provide the compiler 
Rect, comprising four Cartesian coordinates defining the with instructions for properly converting between different 
four corners of a rectangle. value types. For example, in C Language, a source code 
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instruction may assign an integer value to a floating point and unboxed representations. The dual representations of the 

variable (e.g., "float amount«total;", where "total" is a data value type itself may occupy effectively the same storage 

value of type integer and "amount'* is a floating point location or, in an alternative embodiment, in individual and 

number variable). The C compiler can apply the type rules distinct storage locations. In another embodiment, only 

118 to automatically convert the integer "total" into a s those value types interacting with objects are to be boxed, 

floating point number value before generating instructions thereby reducing the size of the output code 108 (i.e., 

for assigning the value to variable " amount". Alternatively, unnecessary metadata is omitted). Furthermore, another 

the compiler 104 may not provide the appropriate type rule embodiment of the present invention may retain a single 

for a given value type combination and operation (e.g., version of the value type (i.e., boxed or unboxed) at a time, 

assigning an "integer" value to a "coordinate" variable). In 10 converting dynamically between the two versions, as 

such situations, the compiler may issue a compiler error or needed. As such, only one version of the value type need be 

throw a runtime exception to signal the error. maintained at any one time, the value type version being 

In an embodiment of the present invention, source code dynamically converted by code generated by the compiler in 

instructions for performing operations between value types accordance with a given operation (e.g., an assignment, a 

and objects by boxing and/or unboxing one or both of the 15 function call with object parameters, etc.). 

operands may be compiled and executed transparently to the In addition, the output code 108 may include metadata in 

developer. In a first example, a source code instruction associated with a value type. Alternatively, the output 108 

indicates that a value with a value type is to be assigned to may include a machine or executable code representation of 

an object (e.g., a value with an "integer" value type is the object created by the boxing operation. In yet another 

assigned to an object of the "Integer" class). To perform such 20 alternative, the machine or executable code representation 

an assignment without boxing would typically cause a may be generated at runtime, as discussed below, 

compiler error because the types of the operands are not Another example of source code instructions performing 

equivalent (i.e., the assignment does not satisfy a type rule). operations between value types and objects by boxing and/or 

Without boxing/unboxing, a compiler does not perform the unboxing is provided in the case in which a boxed value type 

assignment because the "integer" value type is not associ- 25 is to be assigned to a value with a unboxed value type (e.g., 

ated with metadata required to populate the Integer object's an object of the Integer class is assigned to a value with an 

metadata portion (see FIG. 4). integer value type). To perform such an assignment without 

Instead, the compiler 104 detects the discrepancy between unboxing would typically cause a compiler error because the 
types and generates metadata and compiler code to "box" types of the operands are not equivalent. In an embodiment 
the "integer^ value, thereby converting the value type into an 30 of the present invention, however; the compiler 104 detects 
object, so that the boxed value type can be assigned to the the discrepancy between types and generates code to con- 
Integer object If the types include a built-in value type, the verts the object to an unboxed value type by deleting or 
compiler may be pro-configured with the metadata required ignoring the metadata associated with the boxed value type, 
to box the value type. If the types include a user-defined so that the unboxed value type can be assigned to the 
value type, the user can provide the required metadata for 35 "integer" value type. 

the compiler to use in the boxing operation. The metadata FIG. 2 and the following discussion are intended to 

defining a user-defined type may describe a sequence of bits provide a brief, general description of a suitable computing 

(i.e., the value) and includes the type name, field names for environment in which the invention may be implemented, 

all fields in the type, field types for all fields, and operations While the invention will be described in the general context 

that can be performed in association with the type (e.g., 40 of an application program that runs on an operating system 

methods). The metadata defining a user-defined type can in conjunction with a personal computer, those skilled in the 

also include a list of interfaces that the type will implement art will recognize that the invention also may be imple- 

in its boxed form. Finally, the metadata can include an mented in combination with other program modules, 

indication as to where a boxed version of the value type will Generally, program modules include routines, programs, 

fit within the object class hierarchy 116, described below in 45 components, data structures, etc. that perform particular 

connection with FIG. 36. Thereafter, the compiler 104 tasks or implement particular abstract data types. Moreover, 

generates the object code for assigning the "boxed value those skilled in the art will appreciate that the invention may 

type" (or object) to the Integer object. be practiced with other computer system configurations, 

Rather than generate code to box and unbox value types including hand -held devices, multiprocessor systems, 

at the compiler, other embodiments may implement the 50 microprocessor-based or programmable consumer 

concept of dual representation in different ways. For electronics, minicomputers, mainframe computers, and the 

example, if the runtime environment that is the target of the like. The invention may also be practiced in distributed 

code (such as runtime environment 102) can box and unbox computing environments where tasks are performed by 

value types, then the compiler need only output a box or remote processing devices that are linked through a com- 

unbox command as appropriate and the runtime can perform 55 munications network. In a distributed computing 

the actual work. In other implementations, boxed and environment, program modules maybe located in both local 

unboxed representations can exist simultaneously with no and remote memory storage devices, 

need for either the compiler or the runtime environment to With reference to FIG. 2, an exemplary system for imple- 

generate code that boxes or unboxes value types. In other menting the invention includes a conventional personal 

implementations, only the boxed representations may be 60 computer 20, including a processing unit 21, a system 

generated with a mechanism to bypass or ignore the meta- memory 22, and a system bus 23 that couples the system 

data portion when unboxed version is desired. memory to the processing unit 21. The system memory 22 

The output code 108 produced by the compiler 104 includes read only memory (ROM) 24 and random access 

logically includes the compiled objects 120 and both boxed memory (RAM) 25. A basic input/output system 26 (BIOS), 

and unboxed representations (122 and 124) of the value 65 containing the basic routines that help to transfer informa- 

types defined in the source file 100. In one embodiment, all tion between elements within the personal computer 20, 

value types are compiled to logically produce both boxed such as during start-up, is stored in ROM 24. The personal 



06/10/2004, EAST Version: 1.4.1 



US 6,738,968 Bl 

9 10 

computer 20 further includes a hard disk drive 27, a mag- mented in any method or technology for storage of infor- 

netic disk drive 28, e.g., to read from or write to a removable mation such as computer readable instructions, data 

disk 29, and an optical disk drive 30, e.g., for reading a structures, program modules or other data. Computer storage 

CD-ROM disk 31 or to read from or write to other optical media includes, but is not Limited to, RAM, ROM, 

media. The hard disk drive 27, magnetic disk drive 28, and 5 EEPROM, flash memory or other memory technology, 

optical disk drive 30 are connected to the system bus 23 by CD-ROM, digital versatile disks (DVD) or other optical 

a hard disk drive interface 32, a magnetic disk drive inter- storage, magnetic cassettes, magnetic tape, magnetic disk 

face 33, and an optical drive interface 34, respectively. The storage or other magnetic storage devices, or any other 

drives and their associated computer-readable media provide medium which can be used to store the desired information 

nonvolatile storage for the personal computer 20. Although 10 and which can be accessed by personal computer 20. Com- 

the description of computer-readable media above refers to munication media typically embodies computer readable 

a hard disk, a removable magnetic disk and a CD-ROM disk, instructions, data structures, program modules or other data 

it should be appreciated by those skilled in the art that other in a modulated data signal such as a carrier wave or other 

types of media which are readable by a computer, such as transport mechanism and includes any information delivery 

magnetic cassettes, flash memory cards, digital video disks, 15 media. The term "modulated data signal" means a signal that 

Bernoulli cartridges, and the like, may also be used in the has one or more of its characteristics set or changed in such 

exemplary operating environment. a manner as to encode information in the signal. By way of 

A number of program modules may be stored in the drives example, and not limitation, communication media includes 
and RAM 25, including an operating system 35, a source file wired media such as a wired network or direct-wired 
100, a Runtime System 102, and a compiler 104. A user may 20 connection, and wireless media such as acoustic, RF, infra- 
enter commands and information into the personal computer red and other wireless media. Combinations of any of the 
20 through a keyboard 40 and pointing device, such as a above should also be included within the scope of computer 
mouse 42. Other input devices (not shown) may include a readable media. Computer readable media may also be 
microphone, joystick, game pad, satellite dish, scanner, or referred to as computer program product, 
the like. These and other input devices are often connected 25 As described above, in connection with FIG. I, a compiler 
to the processing unit 21 through a serial port interface 46 104 receives and compiles a source file 100 written for a 
that is coupled to the system bus, but may be connected by runtime environment 102 or any other execution environ- 
other interfaces, such as a game port or a universal serial bus ment. FIG. 3a depicts an exemplary value type classification 
(USB). A monitor 47 or other type of display device is also system 300 for the computer language in which the source 
connected to the system bus 23 via an interface, such as a 30 file 100 is written. The source file 100 may utilize both 
video adapter 48. In addition to the monitor, personal built-in value types 302 and user-defined value types 304. 
computers typically include other peripheral output devices Generally, value types define the notion of how to interpret 
(not shown), such as speakers or printers. the bit patterns of data stored in a computer. For example, a 

The personal computer 20 may operate in a networked value may be a simple bit pattern representing an integer or 
environment using logical connections to one or more 35 a floating point number. Each value has a type that describes 
remote computers, such as a remote computer 49. The both the size of the storage that the value occupies as well 
remote computer 49 may be a server, a router, a peer device as the meaning of the bits in the value's representation. For 
or other common network node, and typically includes many example, a value of "2" may be of type "intl6." Type "intl6" 
or all of the elements described relative to the personal indicates that the bits of the value's representation mean that 
computer 20, although only a memory storage device 50 has 40 the value is an integer. Type "int!6" further indicates that the 
been illustrated in FIG. 2. The logical connections depicted value occupies the storage necessary to store a signed 16-bit 
in FIG. 2 include a local area network (LAN) 51 and a wide integer. The type also describes for the compiler the opera- 
area network (WAN) 52. Such networking environments are tions that can be performed on the value's representation, 
commonplace in offices, enterprise-wide computer Generally, for unboxed value types, the type information is 
networks, intranets and the Internet. 45 not emitted into the output code. Type "intl6" is an example 

When used in a LAN networking environment, the per- of a built-in value type in an embodiment of the present 

sonal computer 20 is connected to the LAN 51 through a invention. The previous discussion relating to value types 

network interface 53. When used in a WAN networking can apply to both user-defined value types and built-in types 

environment, the personal computer 20 typically includes a so that they can be efficiently processed at runtime. If the 

modem 54 or other means for establishing communications 50 compiler does not already have access to the metadata for a 

over the WAN 52, such as the Internet. The modem 54, given value type, particularly for user-defined value types, 

which may be internal or external, is connected to the system the user can provide the metadata in a source code file or 

bus 23 via the serial port interface 46. In a networked configuration file. 

environment, program modules depicted relative to the An exemplary list of data types is depicted in FIG. 3a. The 
personal computer 20, or portions thereof, may be stored in 55 list includes a group of built-in value types 302 and a group 
the remote memory storage device. It will be appreciated of user-defined value types 304. User-defined value types 
that the network connections shown are exemplary and other 304 can include virtually any kind of data structure. In most 
means of establishing a communications link between the source languages, a user can create a user-defined value type 
computers may be used. by utilizing combinations of built-in types, such as by 
Computing device, such as personal computer 20, typi- 60 defining a type name, a field name for each field in the type, 
cally includes at least some form of computer readable and a field type for each field. In this one illustrative 
media. Computer readable media can be any available media example, the point data type 306 is a two-value data type that 
that can be accessed by personal computer 20. By way of defines the Cartesian coordinates of a point in a two- 
example, and not limitation, computer readable media may dimensional space. The circle data type 308 is a two-value 
comprise computer storage media and communication 65 data type that includes a value of point data type defining a 
media. Computer storage media includes volatile and circle's center point and a second value of integer data type 
nonvolatile, removable and non-removable media imple- defining the magnitude of the radius of the circle. The 
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rectangle data type is a four-value data type that includes a 
value of point data type for each of a rectangle's corners. 
Notably, the circle data type 308 and the rectangle data type 
310 may utilize the point data type 306. Thus, it can be said 
that the circle data type 308 and the rectangle data types 310 
"inherits" from the point data type 306. In some 
implementations, this may be a true inheritance; in others, 
this may simply imply that one value type is used to build 
other value types. 

A user can create metadata to describe a boxed form of a 
value type. For example, the process of creating a user- 
defined value type may include a step of specifying the 
metadata for that type needed for boxing a value type. 
Typically, the metadata defining a user-defined type 304 
describes a sequence of bits (i.e., the value) and includes the 
type name, field names for all fields in the type, field types 
for all fields, and operations that can be performed in 
association with the type (e.g., methods). The metadata 
defining a user-defined type can also include a list of 
interfaces that the type will implement in its boxed form. 
Finally, the metadata can include an indication as to where 
a boxed version of the type will fit within the object class 
hierarchy 116, described below in connection with FIG. 3b. 
This metadata may be used by the compiler, the loader, 
and/or the runtime environment to verify type safety and 
manage boxed versions of the value type. 

FIG. 3b depicts an exemplary object class hierarchy 350. 
Generally, objects of the class hierarchy 350 are more 
complex data types than value types 300. Each object is 
self- typing, in that each object's type is explicitly stored in 
its representation in the output code. An object has an 
identity (e.g., object name, class name) that distinguishes it 
from all other objects. Each object has fields (or data 
members) that can be used to store other data, including 
values (with associated value types) and methods associated 
with the object. Of course, the fields in an object can 
themselves be objects. An object can also include location 
information (e.g., a pointer) and interface information. The 
objects of a class hierarchy, such as class hierarchy 350, 
typically derive from a base root object. In FIG. 3b, such a 
base root object is illustrated by BaseObject 320. Thus, other 
objects are shown below BaseObject 320 in the object class 
hierarchy 350 and, therefore, inherit from the BaseObject 
320. 

The object class hierarchy of FIG. 36 illustrates the dual 
representation of value types in one aspect of the invention. 
FIG. 3b shows a representative class hierarchy that includes 
the boxed representations of the value types illustrated in 
FIG. 3c. In the object class hierarchy 350, built-in value 
types 352 (e.g., integer 325, floats 326, and Boolean 328) 
and user-defined value types 354 (e.g., point 330, rectangle 
332, and circle 334) are stored as any other object 356 within 
the object class hierarchy. The built-in value types 352 and 
user-defined value types 354 depicted in FIG. 3b are boxed 
value types. Thus, the built-in value types 352 and user- 
defined value types 354 may be processed at runtime on the 
same basis as any other object in the hierarchy. As stated 
above, a boxed value type is created from an unboxed value 
type by associating the unboxed value type with metadata 
providing the boxed value type with object-like attributes. 
Metadata will be described in more detail in connection with 
FIG. 4. 

Notably, a "child" object, such as Object y, inherits the 
attributes of a "parent" object, such as Object x. If a method 
is associated with Object x, for example, then the method is 
also associated with Object y, by inheritance. One aspect 
illustrated in FIG. 3b is that the boxed representations of 



value types may include parent-child relationships, even 
though there is no notion of parent-child relationship in 
value types. For example, in FIG. 3b both circle and 
rectangle derive from point. Similarly, child boxed value 

5 types (e.g., circle value type 334) inherit methods and other 
attributes from parent boxed value types (e.g., point value 
type 330). Such inherited methods are referred to as virtual 
methods. Because of the dual representation of value and 
object types in the present invention, developers need not 

10 worry which form is passed to methods. Thus, an unboxed 
value type may be passed into an object method where a 
boxed representation is expected or vice versa. The compiler 
and/or runtime can select the appropriate representation 
either at compile or run time as appropriate for the particular 

15 implementation. 

The dual representation of value types both as unboxed 
value types and as boxed value types in the object class 
hierarchy implies that value types can have methods and can 
behave as objects in some instances and as unboxed value 

20 types in other instances. The practical effect is that when 
value types are in their boxed representation, they can have 
methods like other objects. When value types are in their 
unboxed representation, they can be valid arguments to 
methods that would otherwise expect an object type (such as 

25 a boxed representation). Because both the boxed and 
unboxed value type representations can be made available, 
this functionality can be provided without the developer 
having to explicitly specify either what version to use or the 
conversion from one form to another. 

30 A data type fully describes a value if it completely defines 
the value's representation and the operations that can be 
performed on the value. For a data type, defining the value's 
representation entails describing the sequence of bits that 
make up the value's representation. Defining the set of 

35 operations that can be performed on a data type entails 
specifying named methods for each operation. A named 
method describes an operation that can be performed in 
association with a data type. 

For an object, defining the object's representation entails 

40 describing the object's location and the sequence of bits that 
make up the object's representation. Thus an object includes 
a definition of the object's contents and the operations that 
may be performed on that object. When an object contains 
a value, this definition includes the value's representation 

45 and the operations that can be legally performed in associa- 
tion with the value (e.g., methods). Defining an object 
entails describing the sequence of bits that make up the 
value's representation (self describing data), the location of 
the object (pointer data), and at least one named method for 

50 the object (interface data). 

Thus, an object differs from an unboxed data type, in that 
an object includes not just raw data (i.e., a value 
representation), but also other data including the location of 
the object. This other data is stored in the object as metadata. 

55 Advantageously, metadata can be stored in a way that is 
independent of any particular programming language. Thus, 
metadata provides a common interchange mechanism for 
use between tools that manipulate objects (e.g., compilers, 
debuggers). 

60 Turning now to FIG. 4, an unboxed value type 400 is 
depicted as containing only raw value data 401 (i.e., a value 
representation). A boxed value type 402 is depicted as 
containing raw value data 401, as well as metadata 404. For 
every value type (built-in or user-defined), a corresponding 
65 boxed value type can be created. Boxed data types have the 
characteristics of objects, as described above, because the 
metadata provides a means for associating the boxed data 
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type with value-describing data, location data, and method processing prior to as illustrated by the separate optional 
data Thus the association of metadata with the boxed value processing section 524 or the integral optional processing 
type permits the storage of the boxed value type within the section 526. Generally, optional processing may involve 
object class hierarchy 320 of FIG. 3b. In an exemplary verification, type checking, and or any translation of he 
embodiment of the present invention, the boxed and S common language file into a form suitable for use by the 
unboxed value types depicted in FIG. 4 can be stored in the runtime environment 522. Hence, optional processing may 
output code 108 (FIG. 1). It should be understood that FIG. be used to translate, interpret or otherwise convert the 
4 illustrates a logical representation of a boxed value type, received common output 61es 514, 516 and 518, into output 
indicating that metadata is associated with the storage loca- code that can be executed in the execution environment 522. 
tion of the value type. » In the case where the execution environment 522 » a 

Functional software components of another system 500 managed runtime environment as shown in FIG 5, then 
that incorporates aspects of the present invention are shown runtime environment itself has a loader 530 which loads the 
in FIG 5 The system 500 incorporates at least one front end files for execution. The loader 530 receives the executable 
compiler' such as compilers 502, 504 and 506, which are not file and resolves necessary references and loads the code, 
intended to show requirements of the present invention but 15 The environment may provide a stack walker 532, i.e., the 
merely to illustrate concepts of the present invention applied piece of code that manages the method calls and provides for 
to multiple or combined front end systems. The front end the identification of the sequence of method calls on a stack 
compilers 502, 504 and 506 are capable of parsing and at a given point in time. A layout engine 534 may also be 
analyzing different types of source language files, such as provided, which establishes the layout, in memory, of the 
source files 508 510 and 512, respectively. These source 20 various objects and other elements as part of the application 
files 508 510 and 512 can include built-in value types, to be executed. The execution environment may further 
user-defined value types, and objects. In this embodiment, provide a security module 536 to prevent unauthorized use 
the front end compilers 502, 504 and 506 each produce a of resources by determining whether certain code has per- 
common language output file 514, 516 and 518. Generally, mission to access certain system resources (or even execute 
compilers 502, 504 and 506 are functionally similar to 25 at all). The runtime environment may further provide 
compiler 104, described in connection with FIG. 1. memory management services, such as a garbage collector 

In an exemplary embodiment of the present invention, the 538, and other developer services 540, such as debuggers 
common language output files 514, 516 and 518 have and profiling. Other types of services that can be provided by 
executable instructions in a "common" (in the sense of a managed execution environment include verification of 
universal) intermediate language suitable for representing 30 code before it is executed, among others, 
the concepts of a plurality of different types of source The execution environment 522 may further ' utilize a 
languages, e.g., procedural, functional and object oriented common library program file 528, which has the actual 
languages, so that only one type of intermediate language implementation informaton to carry out the functionality of 
need be used regardless of the specific source language used. the common library declarations 520^ 
The executable instructions within the common language 35 During runtime, the output files 514 516 and 518 are 
output files 514, 516 and 518 can be either instructions that loaded into the runtime envuonmcnt 522. Importantly, the 
can be directly executed by a processor (e.g., object or native information that is provided to the runtime envu-onment, 
machine code) or an "intermediate" type instruction (e.g. such as the boxed or unboxed value types shown in FIG. 4, 
Java bytecodes, p-code, or other intermediate language) that is used by the runtime environment to shape objects prior o 
^ executed within some type of execution environment. 40 runtime. The layout engine generally uses the information to 
The front end compilers 502, 504 and 506, in addition to create data structures for each of the ypes of classes 
beins able to read and analyze their respective source files including the appropriate method and field mformation. 
508 510 and 512, are capable of reading and analyzing files FIG. 6 depicts an operation flow for boxing and unboxing 
represented in the common language. Moreover, a library an individual value type m an exemplary ^J^™" ° f 
declarations file 520 of functions represented in the common 45 present invention. Because the boxing and unboxing can be 
language is available for use by the front end compilers 502, done automatically both versions of a pamcular data type 
«i(U d 506 can be madc 10 ^ avlllablc at r unt ™ 6 ■ Accordingly, 

Ita common language files 514, 516 and 518, once the most efficient form of the value type can be selectively 
compiled, may be transmitted to an execution environment used, depending on the situation (e.g. assigning an unboxed 
or runtime environment 522. In this application, execution 50 value type to an object). Of course, the conversion can also 
environment and runtime environment are used interchange- be avoided in instances where the compiler 1M determines 
abS X execution environment may be either a direct that the converted form of the value type is not needed, 
execution environment, a managed runtime environment or The logical operat.ons in FIG. 6 are implemented (1) as 
arunmanaged runtime' environment. Advantageously, any a sequence of computer implemented steps or * program 
necessary conversions of unboxed value types to boxed 55 module running on a computing .system and/or (2) as ^.nter- 
Talue typeslor vice versa) may be performed either at the connected logic circuits or machine logic modules within the 
compile? age thereby permitting the use of such converted computing system. The implementation is a ™«« °fchojce 
value types w thout regard to the managed or unmanaged dependent on the performance requirements of the comput- 
es o!Z runtime environment, or by the runtime envi- ing system implementing the invention^ ^^.ngly he 
ronment Indeed the environment may be any other type of 60 logical operations making up the embodiments of the 
nXlent cfpable of reading and executing the compiled present invention described herein are referred to variously 
files 514 516 and 518. The runtime environment 522 shown as operations, steps or modules. It wdl be recognized by one 
L FIG 5 represents a managed environment having a skilled in the art that these operations steps and module 
plurality of features, functions and services, as discussed may be implemented m software, in firmware, in specia 
plurality oi Leauura, ^ purpose digital logic, and any combination thereof without 

Mot to being supplied to the runtime environment 522, deviating from the spirit and scope of the present invention 
each output file 514, 516 and 518 may undergo optional as recited within the claims attached hereto. 
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In one embodiment of the present invention, the opera- 
tions of FIG. 6 start at step 600 and proceed to unboxed test 
operation 602. Test operation 602 detects whether the source 
file includes a trigger requiring an unboxed to boxed con- 
version. An unboxed to boxed conversion trigger can be any s 
entity in the source file that indicates that an unboxed to 
boxed conversion is needed. Examples of unboxed to boxed 
conversion triggers include situations where an unboxed 
value type is assigned to a boxed value type and where an 
unboxed value type is passed to an object expecting a boxed 10 
value type or another object. In both of these example cases, 
an unboxed to boxed conversion would be required. If test 
operation 602 detects that the source file includes a trigger 
requiring an unboxed to boxed conversion, then the opera- 
tion flow branches YES to unboxed value type emit opera- 15 
tion 604. The unboxed value type emit operation 604 emits 
code from the compiler to perform the unboxed to boxed 
conversion, the unboxed value type, and the metadata asso- 
ciated with the unboxed value type to the runtime environ- 
ment via the output code. The operation flow then proceeds 20 
to conversion operation 608, which at runtime converts or 
builds a boxed value type from the emitted code, the 
unboxed value type, and the metadata associated with the 
unboxed value type. Operation flow proceeds to operation 
619 and ends for the converted value type. 25 

Hie boxed value type can include the definition of the 
type name, the field names, field types, and operations that 
can be performed in association with the boxed value type 
(e.g., methods). Creation of the boxed value type can also 
include the creation of metadata representing the appropriate 30 
position of the boxed value type in an object class hierarchy 
and any relationships with other boxed value types. 

Notably, boxed test operation 610 is also reached if a 
determination is made at unboxed test operation 602 that the 
source file does not include a trigger requiring an unboxed 35 
to boxed conversion. Boxed test operation 610 detects 
whether the source file includes a conversion trigger requir- 
ing a boxed to unboxed conversion. If the source file does 
not include a conversion trigger requiring an unboxed to 
boxed conversion, then the operation flow branches NO to 40 
step 612 and ends for the converted value type. 

On the other hand, if boxed test operation 610 detects that 
the source file includes a conversion trigger requiring an 
unboxed to boxed conversion, then the operation flow 
branches YES to boxed value type emit operation 614. The 45 
boxed value type emit operation 614 emits code to perform 
the boxed to unboxed conversion, the boxed value type, and 
the metadata associated with the boxed value type to the 
runtime environment via the output code. The operation flow 
then proceeds to conversion operation 616 and converts or 50 
builds an unboxed value type from the code to perform the 
boxed to unboxed conversion, the boxed value type, and the 
metadata associated with the boxed value type in the output 
code. 

A boxed to unboxed conversion trigger can be any entity 55 
in the source file that indicates that the conversion is needed. 
Examples of conversion triggers include situations where a 
boxed value type is assigned to an unboxed value type and 
where a boxed value type is passed to an object expecting an 
unboxed value type. In both of these example cases, a boxed 60 
to unboxed conversion would be required. The operation 
flow proceeds to step 618 and ends with regard to the 
converted value type. 

It will be appreciated that the operation of FIG. 6 may be 
modified so that a conversion is not necessarily performed 65 
for each value type detected in a source file. A preliminary 
determination may also be made as to whether a conversion 
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is appropriate. For example, a compiler may recognize that 
a boxed, built-in value type is never implemented in its 
unboxed format by the source file. In such a case, a con- 
version may be avoided as unnecessary. 

As discussed, the process described with regard to FIG. 6 
relates to the logical processing of an individual value type. 
Typically, however, multiple value types are included in a 
source code file and may require boxing and unboxing as 
appropriate. In one embodiment of the present invention, the 
detecting operations 602 and 610 and the emitting opera- 
tions 604 and 614 are generally performed for multiple value 
types during a compilation stage before proceeding to the 
converting operations 608 and 616 during runtime. In this 
manner, most (or all) required converting code is emitted 
into the output code for execution during runtime. 

In an alternative embodiment of the present invention, 
however, the detecting operations 602 and 610 and the 
emitting operations 604 and 614 may also be performed 
during runtime. The "emitting" operations are embodied by 
a call to boxing or unboxing code during runtime. Such an 
embodiment is disclosed with regard to FIGS. 7 and 8, for 
example. 

During execution of the object code 106 (FIG. 1), the 
runtime environment, such as runtime environment 522 
(FIG. 5), may determine whether to use the boxed or 
unboxed version of a particular data type as in the imple- 
mentation of a virtual method. In an embodiment, the flow 
700 illustrates a particular situation wherein the runtime 
environment performs the selection operation, as compared 
to the compiler. Initially, the flow generally begins with 
defining operation 702, which defines a particular value type 
that is to be used in a function call. Defining the value type 
generally relates to providing some information as to 
whether the value type is boxed or unboxed. In an 
embodiment, a bit may be associated with the value type and 
the bit is either set or cleared depending on whether the 
value type is boxed or unboxed. 

Once the value type has been defined, pass operation 704 
passes the defined the value type to a particular function. In 
essence during compile time, the compiler emitted code to 
provide for the passing of the value type to the function 
during runtime. Passing a parameter of this sort to a function 
is straightforward and effectively provides the necessary 
value type information to the function for operation. 

The particular function that receives the defined value 
type expects either a boxed or unboxed value type. 
Therefore, following the passing operation 704, determina- 
tion act 706 determines whether the passed value type is the 
same as the expected value type. The determination may be 
a simple testing of a bit associated with the value type or 
some other operation that evaluates the type of data passed 
to the function. 

If determination operation 706 determines that the passed 
value type is not the same as the expected value type, flow 
branches NO to modify operation 708. Modify operation 
either boxes or unboxes the passed value type, and passes 
the new value type to the function. In an embodiment where 
the function expected a boxed value type but received an 
unboxed value type, step 708 boxes the value type. On the 
other hand, had the function expected an unboxed value type 
but received a boxed value type, then operation 708 would 
unbox the value type. The result of the box operation 708 is 
a pointer to an object describing the unboxed value type. 
Following the modification operation 708, flow continues 
with call operation 710, which is described below. 

If the determination step 706 determined that the passed 
value type was the same as the expected value type, then 
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flow branches YES to call operation 710. Essentially, had the 
function received a value type that was expected, no 
modification, such as modification operation 708, would be 
necessary. Thus, flow continues with call operation 710. 

Call operation 710 calls a member method associated with 5 
the defined function. The method may be a virtual method, 
e.g., wherein the compiler could not determine one certain 
method to call at compile time and therefore implemented 
multiple versions, such as in the case with superclasses or in 
the case wherein the function may receive both boxed and 10 
unboxed versions of value types. The member method is 
related to a user defined method for operating on the passed 
value type. At compile time, the compiler emits the code for 
performing the various methods within the function. 
However, since the function may receive different types, the is 
compiler does not insert the specific code within the function 
for each type. Instead, the compiler creates a virtual method 
table. The virtual method table comprises the necessary 
information to perform the method for each of the specific 
value types that the function may receive. 20 

Therefore, once the method has been called at 710, the 
runtime environment executes the method call using the 
reference to the appropriate method in the virtual method 
table. More specifically, lookup operation 712 looks up the 
particular method related to the passed value type. Once the 25 
particular method for that type is found, execute operation 
714 executes the method for that value type. 

As stated, the above -described flow of operations is able 
to handle either boxed or unboxed parameters. A key feature 
relates to the use of a virtual table to provide methods for the 30 
different value types that may be passed to a particular 
function. Since the function may receive different types and 
since the compiler is unaware of which type the function will 
receive, the runtime environment performs the necessary 
analysis and resolves any discrepancies between value 35 
types. 

A flow 800 of operations in an alternative embodiment to 
that shown in FIG. 7 is shown in FIG. 8. The first two acts 
of flow 800, define operation 802 and pass operation 804 are 
similar to acts 702 and 704 described above in conjunction 40 
with FIG. 7. That is, define operation 802 defines the value 
type as boxed or unboxed and then pass operation 804 passes 
the value to the function. 

Once passed, call operation 806 then calls the member 
function. This act is similar to call operation-710 described 45 
above wherein the actual method is called. Following the 
call operation 806, lookup operation 808 looks up the called 
method for the passed value type in the virtual method table. 
Lookup operation 808 is similar to operation 712 described 
above. 50 

Following call operation 806 and lookup operation 808, 
determination act 810 determines whether the passed value 
type is the same as the expected value type. Determination 
act 810 is similar to the determination act 706 described 
above in that the passed value type is analyzed against the 55 
expected form of the value type. One difference, however, is 
that the code for performing the determination act may 
actually reside in the front portion of the called method code, 
as described below. 

If the determination act 810 determines that the passed 60 
value type is different from the expected form, then flow 
branches NO to modify operation 812. Modify operation 
812 is similar to modify operation 708 described above in 
conjunction with FIG. 7. Essentially, if the modification is 
necessary, modification act 812 performs the necessary acts 65 
required to box or unbox the value type as needed, (e.g., 
calls appropriate boxing or unboxing code). Once modified, 



execute operation 814 executes the method using the modi- 
fied value type. 

If, on the other hand, determination act 810 determines 
that the passed value type is the same as the expected value 
type, then execute operation 814 performs the method using 
the passed value type. Since the passed value type was the 
same as the expected value type, then no modification act, 
such as act 812, is needed prior to execution. 

The embodiment shown in FIG. 8 allows the caller object 
to simply call a method and pass a value type to that function 
that performs the method. The caller does not have to make 
a determination as to whether the value type is correct. Such 
a caller object may then be streamlined such that it performs 
fewer operations. The tradeoff, however, is that the method 
or some other module must perform the determination 
operation. In essence, the plumbing may reside as a small 
portion of code that is performed prior to the execution of 
the method. When the number of callers outweighs the 
number of called methods, such a streamlining of the caller 
objects may be helpful 

Thus, the present invention is presently embodied as a 
method, apparatus, or article of manufacture, such as com- 
puter readable media or program product containing a 
computer program, for processing objects of various pro- 
gramming languages and for boxing and unboxing a user- 
defined data type. While the invention has been particularly 
shown and described with reference to preferred embodi- 
ments thereof, it will be understood by those skilled in the 
art that various other changes in the form and details may be 
made therein without departing form the spirit and scope of 
the invention. 

What is claimed is: 

1. A unified type system for use with a computer source 
language and associated components which translate source 
files written in the computer source language into executable 
form and execute the translated source files, wherein at least 
one source file declares a variable using an unboxed value 
type yet passes the variable to a method expecting a boxed 
value type representation, the unified type system compris- 
ing: 

a first value type representation relating to the unboxed 
value type representation of the variable; and 

a class object hierarchy comprising a plurality of object 
classes, wherein at least one of the object classes is a 
second value type representation relating to the boxed 
representation of the variable, and wherein the second 
value type is automatically passed to the method 
expecting the boxed value type. 

2. A generated output file produced by a front end 
compiler system, wherein the front end compiler system is 
adapted to compile other common language files, the gen- 
erated common output file comprising: 

an unboxed value type representation; 

metadata corresponding to the unboxed value type rep- 
resentation for converting the unboxed value type rep- 
resentation into a boxed value type representation; and 

output code generated from the front end compiler system 
converting between the unboxed value type represen- 
tation and the boxed value type representation in 
response to a detection of different value types in a 
runtime operation. 

3. A generated output file as defined in claim 2 wherein the 
metadata defines one or more interfaces and wherein the 
boxed value type representation implements the defined one 
or more interfaces. 

4. A generated output file as defined in claim 3 wherein the 
boxed value type representation inherits one or more inter- 
faces. 
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5. A method of performing a method call by a function, 
wherein the function expects parameters of a predetermined 
value type, the method comprising: 

passing a value type to the function; 
calling the requested method using the passed value type; s 
looking up the method within a virtual method table; 
comparing the passed value type to the expected value 
type; 

if the value type is different from the expected value type, 10 
modifying the value type to match the expected value 
type; and 

executing the method using the value type. 

6. A method as denned in claim 5 wherein the passed 
value type is an unboxed value type and the predetermined 15 
value type is a boxed value type. 
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7. A method as defined in claim 6 wherein the unboxed 
value type is associated with metadata, the metadata defin- 
ing a list of interfaces for the boxed value type, and wherein 
the method further comprises: 

implementing one of the interfaces of the boxed value 
type. 

8. A method as defined in claim 7 wherein the metadata 
is defined by the user. 

9. A method as defined in claim 8 wherein the boxed value 
type inherits one or more interfaces from other boxed value 
types. 

10. A method as defined in claim 5 wherein the method is 
performed at runtime. 

U. A method as defined in claim 10 wherein the modified 
type value is not stored in a parameter list. 
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